Traditional internet distribution of non-live content generally employs a unicast delivery system. Also, when unicast is used, it is generally the exclusive method of transmitting content. Unicast communications send one copy of each data packet to each intended recipient. However, unicast presents scaling problems, when the group of recipients is large. In unicast, the network must carry one copy of the same content data for each destination client, thus requiring additional bandwidth for data transmission. Thus, the server and network resources required are directly proportional to the number of receiving clients.
Non-live content, as referred to herein, is generally a download defined by a fixed length text, video, audio and/or data file. The entire content is preferably recorded and/or defined prior to initiating delivery. Examples of such content files include one or more software applications, movies, videos, music, news, periodicals, journals, magazines or electronic documents. Thus, non-live content can include non-time critical downloads, such as a new software release. The start time, end time or download speed for delivery of such non-time critical content is not necessarily significant to the end user. Also, non-live content can include more time critical downloads, such as a popular new movie release, which must be displayed to the end user in near real-time shortly after the download is initiated. However, both of these examples are distinguished from live content, whose entirety is not well defined at the start of delivery. A defining characteristic of non-live content delivery is the lack of synchronicity, in terms of both time and download bandwidth, amongst receiving clients.
IP multicasting (also referred to as simply “multicasting” or “multicast”) provides a useful way for a source to transmit a stream of content data to a group of recipients. Multicasting transmits only one copy of the data packets from the content source server and allows multicast enabled routers to do the work required to optimally replicate and deliver that packet to each intended recipient Like unicast, when multicast is used, it is generally the exclusive method of transmitting content. Multicast uses the concept of a group to route its data. A group of receivers subscribe to a particular multicast transmission. The individual receivers of the group need not physically or geographically be located near one another. Similarly, the data can be transmitted to the group from one or more sources located virtually anywhere, as long as they can communicate with the receivers through a common network of computers, such as the Internet.
Rather than transmitting multiple copies of data packets, with one copy going to each receiver's IP address as in unicast, multicast transmits one copy of its data packets to a designated multicast group address. Each source in a multicast session transmits data which is assigned to that source's IP address and the designated multicast group's IP address. This address pair is generally represented by the notation (S, G), where S is a source IP address and G is the group IP address.
Traditionally, no two sources would transmit to the same multicast group having the same (S, G) IP address pairing. However, for reliability, two or more sources can be assigned an identical IP address S transmitting the same content to the same group address G. This type of source addressing is referred to as an Anycast source address. With an Anycast source address each multicast-enabled router in the network can select and join the multicast tree of the nearest available source, which will result in two (or more) disjoint multicast trees when multiple Anycast the sources are in operation. When one of the Anycast sources fails, an automatic rerouting mechanism of the multicast-enabled routers previously on the tree of the failed source will select and join the tree of the nearest remaining source(s). Further information on multicasting is provided in U.S. Pat. No. 6,501,763, which is incorporated herein by reference.
While multicast is very resource efficient, it is historically considered unsuited for delivery of non-live or non-simultaneous content due to the lack of synchronicity amongst the receiving clients and that a uniform delivery stream bandwidth (BW) cannot be assured. Delivering non-live content through multicast is further disfavored due to problems associated with data loss. Data loss has a potentially more significant impact in multicast than in unicast transmissions. The distribution of routers in a multicast session generally has a tree-like configuration with numerous branches. Thus, this multicast configuration means that when packets are lost in transit, all recipients on downstream branches from that point lose the same packet(s). Such data loss has various sources, such as congestion or irrecoverable errors in the network.
In order to improve network and server resource efficiencies when using unicast, methods such as local network server caching and peer-to-peer (P2P) redistribution techniques have been used. Local caching uses multiple local servers to receive a content stream from the origin servers and deliver the content to individual receivers closest to them. While reducing the distribution burden to some network resources, local caching does not reduce the burden on content servers and their network-access links. While current P2P delivery can reduce the burden on the CP's content servers and access links, it is not network-optimized; it can actually worsen the burden on the long haul network by substituting long-haul network efficient delivery by local cache servers with inefficient delivery by distant P2P sources. P2P takes advantage of the computing power of individual user computers. Any user participating in a P2P-based delivery acts as a content host by downloading the content from the Content Provider (CP) server(s). In this way, each participating P2P host becomes a server for other receivers that are in the process of downloading or will in the future download the content. However, while being more server efficient, P2P burdens tend to increase network transmission distance and therefore network resource usage, thus further reducing network efficiency. Also, in the case where P2P hosts are connected via the internet, since many individual internet users have very limited upstream bandwidth, P2P becomes less viable as CP's start increasing BW requirements for particular content streams.
Additionally, during the course of content delivery, there is generally a great deal of uncertainty and unpredictability regarding the level of demand for any particular content. High/low demand periods can fluctuate and the popularity of particular content can increase and decrease dramatically. This makes capacity planning difficult for a CP who generally pre-plans their network-access and server capacities, in order to ensure an adequate supply of servers and network access link resources devoted to each content stream. Once a distribution plan for content is decided, a CP does not typically change it during a delivery period, even though content demand in that period may be very different from what was predicted.